Skip to content

fix: defer VS Code auto theme to platform - #841

Open
vamshikrishnaramasamy wants to merge 1 commit into
CodebuffAI:mainfrom
vamshikrishnaramasamy:fix/vscode-auto-theme-platform
Open

fix: defer VS Code auto theme to platform#841
vamshikrishnaramasamy wants to merge 1 commit into
CodebuffAI:mainfrom
vamshikrishnaramasamy:fix/vscode-auto-theme-platform

Conversation

@vamshikrishnaramasamy

@vamshikrishnaramasamy vamshikrishnaramasamy commented Jul 3, 2026

Copy link
Copy Markdown

Fixes #834.

When VS Code has window.autoDetectColorScheme enabled, the CLI should defer to the platform theme detector instead of inferring the theme from workbench.preferredDarkColorTheme first. Otherwise auto-detect can stick to the preferred dark theme even when macOS is in light mode.

This keeps explicit workbench.colorTheme handling unchanged and adds focused coverage for the VS Code settings parser.

Tests:

  • bun test src/__tests__/utils/theme-system.test.ts

Note: bun run typecheck currently fails on unrelated existing react-dom/server declaration errors in CLI component tests.

@codebuff-team

Copy link
Copy Markdown
Contributor

Good, focused change. The reasoning in the PR body matches the diff: when window.autoDetectColorScheme is true, VS Code is following the OS theme, so inferring from workbench.preferredDarkColorTheme/preferredLightColorTheme was wrong — it would always land on whichever theme was configured, ignoring actual OS state. Returning null and letting the caller fall through to platform detection is the right fix, and it's a one-function change in cli/src/utils/theme-system.ts that's easy to review.

The added test in cli/src/__tests__/utils/theme-system.test.ts covers both the explicit-theme path and the auto-detect-defers-to-platform path, which is exactly what the repo would want for this kind of regex-based parser.

One thing to double check before porting: previously, if auto-detect was enabled but the caller's platform detection failed (e.g., non-macOS/unsupported OS), the code would fall back to inferring from preferredDarkColorTheme/preferredLightColorTheme as a best-effort guess. Now it always returns null in that case, so the caller needs a sensible final fallback (e.g., default theme) for those situations, or you risk a regression on platforms without OS-level detection support. Worth confirming the caller (getSystemTheme or wherever this is consumed) handles that gracefully.

Also, minor: exporting extractVSCodeTheme for testing is fine but check whether the codebase has a convention (e.g., barrel test-only exports) for exposing internals like this.

Overall: correct root-cause fix, small diff, includes tests. Worth porting with a quick check of the fallback behavior.

@codebuff-team codebuff-team added bot:triaged Classified by the community triage bot pr:port-candidate Worth porting into the private source tree labels Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bot:triaged Classified by the community triage bot pr:port-candidate Worth porting into the private source tree

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MacOS CLI light theme and dark theme auto detect does not work

2 participants